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(54) Method and apparatus for structured communication 

(57) Method of and apparatus lor point-to-point 
communication between a sender (SRV(m)) and a 
receiver (SRV(m)) by means of messages with flexible 
message formats (ILMF) wherein any of said messages 
includes: 



a header with at least message definition refer- 
ences (MSG ID, MSG CLASS, MSG VERSION, 
MSG CREATOR), a sender identifier (SENDER ID) 
and a destination address (DESTINATION 
ADDRESS); 

message content regarding: 

* number of fields (FIELD COUNT) and content 
of any field (FIELD(1), ...); 

* number of objects (OBJECT COUNT) and con- 
tent of any object (OBJECT(1), ...). 
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Description 

Field of the Invention 

5 [0001 ] The present invention is in the areas of electronic data communications, database organized, flexible format 
electronic data message management, client-server and distributed software applications. 

[0002] In particular, this invention uses a relational database to describe and manage the creation, communication, 
interpretation, display and real-time responses to f lexMe format electronic data messages and applications organized 
as collections of flexible format electronic data messages which may be optionally distributed across one or more conv 
70 outer systems on one or more electronic data networks. 

Background of th? Invention 

[0003] General purpose and business specific electronic data communication meets with four distinct problems, each 
is of which has many sub-problems. We will be discussing these issues with regard to business communication needs, 
although the following points can apply to almost any category of electronic data communications. The four problems 
are: 

1) The electronic data that is sent and received must be clearly recognized for what rt is meant to be. Each company 
20 has a different way of representing even the most basic business information, an order form or bill of lading, for 

example. 

2) Once electronic data is received from another company and correctly recognized, it must be integrated into the 
receiving company's databases and business processing programs. Here again, each company has many differ- 
ences in their database structures, which means the way they represent and store their electronic data on their 

25 computer systems. 

3) If the electronic data must be displayed to an end user and allow for end user interaction, here again, each com- 
pany may be using different types of computer display terminals with various types of display software, various sys- 
tem requirements and business requirements. It is very often necessary to build very expensive electronic data 
display programs with customized graphical user interfaces. 

30 4) There may exist the need to execute the processing of computerized business functions in a coordinated man- 
ner, distributed across more than one computer system, due to the need to use a combination of specialized sys- 
tem services and their associated data to accomplish specific business functions. This means that a computerized 
business system might need to exist in more than one location, operate differently in one or more locations, but 
function, in essence, as if it were one, single system. The solutions to this problem are usually classified as distrib- 

35 uted applications or, more recently, distrixited object management systems that are classified as "middleware*. 

[0004] There are realty two distinct primary issues associated with problem four. The first is the need or desire of a 
company to use the same business application on many different systems, avoiding the need to rewrite the business 
logic, user interface and network communication interface for each different system that it needs to run on. The second 
40 issue is the need to divide the functionality of a single application over more than one system across a communications 
network, and have it operate in a fully coordinated manner. 

[0005] There is no single system currently that can solve all of these four problems. Businesses waste millions of dol- 
lars each year, buying, building, rebuilding and maintaining electronic data communication and storage systems that 
inefficiently and incompletely solve various combinations of these four problems. 

45 

Prior Art 

Problem 1 

so [0006] To solve the first problem, a set of electronic data formats for particular types of information must be agreed 
upon by all communicating companies before the communication actually takes place. Furthermore, the agreement 
upon the formats must be actualized by the use of communication software that uses these same exact agreed upon 
formats. EDI (Electronic Data Interchange) has been one approach to solving this problem. EDI is a set of electronic 
data message formats for many types of business transactions. The formats are not flexible, meaning they cannot be 

55 changed by the users, and there are quite a few different versions of EDI messages. A company could implement an 
EDI message business communication system and still not be able to exchange electronic data with other companies 
using a different version EDI message set The amount of time and money it takes to convert an existing business sys- 
tem to EDI is enormous and it is then difficult and expensive to change to, or add another format if that becomes nec- 
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essary. 

[0007] Methods and solutions using hard-coded (i.e. defined in the software) message formats have all of the prob- 
lems associated with EDI and in essence are the same solution, only with a different fixed message format Every time 
that a fixed message format must be changed, this requires a similar change in the software as well as possibly the 
5 database and user interface. Even a very small change can sometimes take months. And, of course, this electronic 
message format must be changed on the computers of every business using that particular format to insure that future 
electronic communication will continue correctly. 

[0008] Essentially there will always be the requirement that, in some way, a common data format must be agreed upon 
by the sender and receiver. This will be present in any method available, now or in the futura The critical issues for the 
10 customer are: hew fast and cheap it is to build a system around a method (i.e.: EDI) and how easy it is to change a pre- 
viously agreed upon electronic data format in every part of the system (database, software, user interface). 

Problem 2 

75 [0009] The second problem is one that is harder to solve. In general, most cornpanies use large numbers of data entry 
personnel, who are reading printed material and entering the data that they have read into a computer program running 
on their terminal that will process this data, convert it to the correct format and place rt in the company database Those 
companies using EDI or a similar common electronic message format will quite often have paid a very large amount of 
money for customized software that processes and converts the common electronic message format automatically for 

20 them and interacts with their existing database structure for the purpose of data storage and retrieval. If they need to 
change or add to the common message format, or they need to change or expand their database structure then they 
must spend time and much money to have this electronic message format database interface program changed and re- 
written again. 

[0010] One newer public domain general purpose solution centers around "mapping" specific data items to specific 
25 locations in a customer database or storage device. This mapping is not created in software, but is in some more easily 
changeable and flexfole representation that is separate from the software application and customer database, such as 
an independent flat file that the software application reads. This eliminates the need to reprogram and rebuild the soft- 
ware application every time the database structure or the data representation changes. Data field mapping techniques 
are in common use by many database companies such as Progress, Oracle and SQLBase (SQL = Structured Query 
30 Language). A version of this well know method may be part of the functionality and methodology incorporated into com- 
munication apparatus of the present invention. 

Problem 3 

35 [001 1 ] The third problem has had few easily workable general purpose solutions. One category of solutions requires 
writing extensive amounts of software code for various window (graphical user interface) management systems such 
as X-Windows or Microsoft Windows. For large, mufti-functional business applications, this approach requires a tremen- 
dous amount of time, money and effort and makes changes or additions to the user interface a very time consuming 
and costly affair as well. 

40 [0012] A new and promising category of solutions centers around the use of HTML (Hyper Text Markup Language) 
and web browsers, which can dynamically create very nice looking graphical user interfaces, usually called *web pages', 
because they are used on the World Wide Web and the internet This has aroused the interest of many companies. 
They see hew quickly and cheaply very nice looking graphical user interfaces can be built using HTML and they wonder 
if the user interfaces for their electronic data communication and processing programs could be created in the same 

45 way and communicate over the same networks as the web browser systems. In fact companies would like to be able 
to use the internet to send and receive the full range of business and personal data and messages. 
[0013] At the present time there are several systems available that wfll allow a limited range of business and general 
data communication over the internet, using HTML and web browsers. The reason that the types of data communica- 
tion are limited is that the web-server/web browser systems were not designed to provide full data communication serv- 

so ices. They were designed as dynamic document retrieval and display systems. They can retrieve information that is first 
initiated as a request from the user. They do not give the user the capability to send information to one or more desti- 
nations, except by extensive additional programming. The capability for sending is not inherent in the system. Examples 
of this type are Progress' WebSpeed. IBM's WebEDI and SapphireGroup's Page-Blazer. 

[001 4] Even the "newer" features of web browsers and webservers that implement the so-called "push" technology 
55 only allow the receipt of data, not the sending. And this "receipt" is actually set up as a simulated broadcast receiver, a 
hidden repeating request for information (polling), by the web browser and webserver systems. The plans to expand this 
"push" technology only include the use of true broadcast and multi-cast rommurucations technology. Examples of 
"push" technology are Marimba's Castanet and Tbco's TIB API. This so-called "push" technology is of great interest to 
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advertisers that wish to reach a mass market in a new way, but is off almost no use to the company or individual wishing 
or needing to use the advanced document display features of HTML and the Internet in the context of fully integnted 
two way communication of information using point-to-point protocols that can be easily integrated into their existing 
database and business systems. 

5 [001 5] The webserver and web browser interfaces for the Internet are set up to allow end users to send messages as 
requests for web pages. At no time will a web browser user be able to send a message to another web browser user, 
or send a web page to another web browser user, except through electronic mail. At no time will a web browser user 
ever receive a specific message that was not first asked for; even the so-called "push" technology information Is 
requested by polling and the nature of the information, even when it is customized can be compared to a television 

10 broadcast or a mass mailing. The information is not being sent to one specific recipient Contrast this with electronic 
mail (email), for instance. Using email services one can receive any number of specific private, messages without ask- 
ing the sender for them first One can send any number of specific, private messages to particular recipients, without 
first being asked. This is the ordinary and necessary nature of messages. Yet the webserver systems of the internet 
were not designed to communicate like this. 

is [001 6] Why then are companies and people so interested in using them this way? Why donl they just use email? The 
answer is that email does not have any data formatting services built into it (as HTML does) and does not have any user 
interface generation system built into it (as web browsers do). An email message may also take an indeterminate 
amount of time (several seconds to several days) to reach its destination and sometimes can get lost. This is unaccept- 
able for standard business electronic data communications. That is why companies and people like the webserver/web 

20 browser system, which has a very good data display capability built into it and moderately fast communications. How- 
ever, as mentioned above it does not have point-to-point communication capability or data representation and mapping 
capability. 

[0017] In the present invention the public domain HTML standard may be incorporated as the solution for generating 
very easily built fast and flextole graphical user interfaces. 

25 

Problem 4 

[0018] Historically, problem four has been addressed in a genera) way, until very recently, only by Relational Database 
Management Systems (RDBMS). This class of solutions has been and is restricted to solving the proper functionality 
30 of distributed query and distributed database management and does not address the primary two issues of problem 
four as described earlier. 

[001 9] A second and newer class of solutions are to be found in systems currently referred to as "middleware" or dis- 
trfouted object management systems. A good example of this is a system called CORBA (Common Object Request 
Broker Architecture). An excellent set of articles on the development history of CORBA, the goals, current functionality 
35 and deficiencies of CORBA 2.0 can be found in Warren Kayffill, "CORBA masterminds object management" , pi 42, 
DBMS magazine, volume 10, number 3, March 1997, and TJ. Hart "Questioning CORBA. Bringing Corba-based 
designs to life faces a multitude of obstacles", p. 52 in the same issue of DBMS. 

[0020] This class of solution does not address the database interoperability issues, the common data format issues 
at the application level or user interface issues. It addresses solely the ability to write an application with standard com- 
40 munication interfaces and standard data at the communication level. Essentially this type of system supplies a devel- 
opment environment, a run-time environment and set of software fibraries that allow programmers to create 
applications that will run on any system and, after defining data structures in the code (so-called objects), these data 
structures can be exchanged with other software programs that have been coded to recognize and use those particular 
data structures. 

45 [0021] This capability and functionality is, in essence, not any different than a programmer writing a message com- 
munication system in Java, which runs on almost any system, and using either EDI messages or some other agreed 
upon fixed format as a communication medium. The CORBA system does not interpret any messages. The application, 
written by the programmer, must be able to recognize the message This leaves a CORBA application with all of the 
same issues for cost and time of development alteration and maintenance as an EDI or fixed message format applica- 

50 tion system. Even the distributed functionality that is posstote with CORBA is not inherent in CORBA, but in the skill of 
the programmer designing and coding the application and use of the CORBA cxxnmunication lixaries. In essence, the 
only apparent gain of CORBA is the interoperability of pad of an application system across many run-time environ- 
ments, which can perhaps be better gained through other means, such as Java. 

[0022] In essence, it appears that "middleware" in most cases is in fact Just another electronic data communication 
55 environment that offers a standardized communication environment and some standardized software functionality on 
many computers, but fails to address all of the aspects of software application building and so requires the use of sys- 
tem dependent code for database interfaces and user interfaces, thereby defeating the main purpose for the use of a 
system such as CORBA. 
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[0023] There are some systems that are merging CORBA functionality into Java and also including a standardized 
database interface called ODBC, or in the Java system JDBC. This is an interesting development, but as the ODBC 
database interface is only efficient for read-only queries, standard business transaction systems, which require full 
database access, can not be successfully created. Also, this combination does not address problems one or two at all. 
5 In addition, it is not the desired platform on which to build the present invention due to the use of ODBC and the 
unwieldy overhead of the CORBA object broker system. 

[0024] Further prior art is Known from some patent documents which will be briefly discussed below. US 5,257,369 
(Tfoco, Inc) discloses "middleware" presented earlier. In addition, this document provides broadcast functionality and is 
based upon broadcast functionality. It is primarily to provide a solution to the problem of delivering real-time data to 
io many recipients at once, such as in real-time stock quotes or market information, and does not address point-to-point 
communications or problems 2 or 3 at all. The message format is able to be changed and also defined as a data struc- 
ture or object as described in CORBA earlier. However, this capability does not address the ability to change or add a 
message format without changing application code, or the ability to map the data of a message format to either a user 
interface or database fields. 

is [0025] WO 96/20553 (Alphanet Telecom, Inc) focuses upon the enhancement of electronic mail (email) services to 
include voice mail and facsimile (fax) information. The description of the system is of a centralized service which users 
can connect to for the receipt of voice mail, email or fax through the Internet, phone or fax machine connecting to the 
same servica This invention does not address in any way problems 1 , 2, 3, or 4, but does address a way of possibly 
making email more efficient from a communications point of view. 

20 [0026] WO 96/34341 (Charles Bobo II) focuses upon a centralized service, that collects, stores and allows access to 
data for connected users. This is entirely different from the point-to-point communications necessary to solve problems 
1 through 4 and for most types of standard business communications. In addition, there are many commercially availa- 
ble systems that have been in existence for many years that already function in exactly this way, such as GE1S and the 
IBM private data network, to name only two. 

25 [0027] EP-0,747,840 A1, EP-0,747.841 A1, EP-0,747,842 A1, EP-0.747,843 A1, EP-0,747,844 A1, and EP- 
0,747,845 A1 (all of International Business Machines Corporation) are focused upon enhancing the current webserver 
functionality with some forms of database access and so are therefore stall bound by the communications D notations of 
webservers discussed earlier. Therefore this set of inventions can not solve problems 1 and 4 at all and 2 and 3 in only 
a limited way. In addition, there are several commercially available systems that appear to offer the same or even more 

so functionality in webserver enhancement such as WebSpeed from Progress Database Corporation. 

[0028] WO 95/1 1560 (Sybase. Inc.) is in the category of "middleware" that solves only the problem of creating a con- 
sistent electronic data communications software interface which applications may be built upon, regardless of the com- 
puter hardware or operating system being used. This document does not address the format of the electronic data 
being communicated in any manner and so this solution is very similar to CORBA and has afl of the same limitations 

35 from the point of view of the four problems being addressed by the present invention. 

[0029] EP 0 421 624 A2 (Texas Instruments Incorporated) is a combination of a "middleware" system such as 
CORBA, and an application development environment Using a database controlled and administered software devel- 
opment environment, the claimed invention allows programmers to develop applications in C, COBOL and SQL The 
database contains information which allows large grotps of programmers to develop, modify and use source code con- 

40 trol techniques for complex database transaction applications. The database also contains information that aOows the 
application to be recompiled on alternate hardware systems and function in the same manner on each type of compu- 
ter, although in this document mostly IBM mainframe systems and some Unix systems are discussed. The end result 
is a series of hard-coded, compiled applications, with all of the same issues as described in problems 1 and 2 and only 
partially solving problems 3 and 4. 

45 [0030] Given the above, an urgent need arises for a single system and a way of communicating that can solve each 
of these four issues and combine the solutions into one unified whola This would be of great benefit to the individuals 
and companies that must build complex electronic data communication systems and who must face these issues on a 
daily basis. Such a system and communication method would reduce the time, cost and complexity of building and 
maintaining electronic data communication systems drastically. 

so [0031 ] To obtain the object referred to above, the present invention claims a method of point-to-point communication 
between a sender and a receiver by means of messages with flexible message formats, characterized in that any of the 
messages comprises: 

- a header at least comprising message definition references, a sender identifier and a destination address; 
55 - message content regarding: 

* number of fields and content of any field, ...); 

* number of objects and content of any object, ...). 
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[0032] Moreover, in accordance with the present invention, a communication apparatus is claimed which comprises 
processing means and a database, arranged for point-to-point communication with another communication apparatus) 
by means of messages with flexible message formats, the messages comprising: 

5 - a header at least comprising message definition references, a sender identifier and a destination address; 
- message content regarding: 

* number of fields and content of any field , ...); 

* number of objects and content of any object, ...); 

10 

the processing means being arranged for consulting a predetermined message definition table stored in the database 
using the message definition reference as a reference to the predetermined message definition table. 
[0033] Thus, in the present invention a flexible message format is defined that can contain any type of data and that 
contains enough information to fully describe the data within the message itself. Any message comprises message def- 

is inrtion references which are used by the claimed communication apparatus receiving the message to identify a mes- 
sage definition preloaded in its database. However, the technology is flexible since the preloaded message definition is 
not fixed for once and for all. Within the communication apparatus receiving the message, message format specific 
instances can be created, edited or deleted by inserting, updating or deleting entries in relational database tables which 
fully describe the message and reference it with a unique identifier. Moreover, if message definitions are absent at a 

20 desired location, entire database message definitions may be exchanged automatically for particular messages or 
groups of messages, thereby creating easily exchanged common format messages for multiple users. A further advan- 
tage of the present invention is the small amount of necessary overhead. 

[0034] Examples of fields within the message definition references are a message identifier for identifying any of the 
messages, a message class identifier for identifying a message class for any of the messages, like mail, business mes- 
25 sage, orders or shipping, a message version identifier for identifying a version number of any of the messages, and a 
message creator identifier for identifying a creator of any of the messages. Any of these fields within the message def- 
inition references have equivalent counterparts within the message definition table in the claimed communication appa- 
ratus. 

[0035] Moreover, headers of messages may include a reference to a type of encryption and/or compression used. 
30 Also these references, then, have counterparts in the message definition table in the communication apparatus. 
[0036] Preferably; the content of messages is protected by digital signatures. 

[0037] Preferably, the database of the communication apparatus is organized in several tables to which reference is 
made from the message definition table. Then, the predetermined message definition table comprises a message sys- 
tem identifier for use as a reference to further tables in the databasa 
35 [0038] One of such further tables may be a field definition table for holding primary definitions for any field of the mes- 
sages. 

[0039] Preferably, one of such further tables is a field mapping table comprising mapping information usable by pre- 
determined fields, e.g. for mappings to hyper text markup language fields, database fields, flat fQe fields and other mes- 
sage fields, said database fields and flat fie fields being stored in a customer database. Then, the message format 

40 according to the invention contains not only data, but also mapping commands for user interfaces, customer database 
fields, and sequences of actions including calculations and conditional logic. Consequently, all of the elements for defin- 
ing application level functionality are present in the message format, which is already in the context of a network com- 
munication system and therefore may be easily distributed by simply changing a location and destination address. 
Moreover, in this way the HTML standard may be incorporated for generating very easily built, fast and flexible graphical 

45 user interfaces, allowing a direct mapping to and from the message format defined by the invention, as managed, 
defined and controlled by the claimed communication apparatus and displayed and interacted with on a user terminal, 
like a microprocessor, connected to the communication apparatus. 

[0040] Additionally, one of such further tables may be a field action table comprising action information usable by pre- 
determined fields. 

so [0041] Preferably, further tables are a message pre-processing table comprising a list of actions to be executed as 
pre-processing tor a message either received or to be sent and a message post-processing table comprising a list of 
actions to be executed as post-processing for a message received. 

[0042] The field action table, the message pre-processing table and the message post-processing table comprise ref- 
erences to types of action selected from the following group of actions: mathematical calculations, assignments, logical 
55 operations, conditional operations, and commands. 

[0043] Preferably, in the present invention, applications are defined as a named group of one or more messages. To 
that end, the message definition table comprises an application field for indicating whether a message received is a first 
message of an application and an application name field for referring to a name of the application. 
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[0044] In accordance with the present invention, the claimed communication apparatus is, preferably, arranged for 
requesting a new message definition from a sender if a message received refers to a message definition not present in 
its database, and receiving said new message definition from said sender and storing it in said message definition table 
in said database. 

5 [004$] The processing means of the communication apparatus may be arranged to either merge a message received 
with a designated HTML file or if the designated HTML file is not found by the processing means, to create a default 
dynamic HTML file. However, alternatively, the processing means of the communication apparatus may instruct a con- 
nected terminal to carry out these functions. Therefore, the present invention also relates to a system comprising a 
communication apparatus as defined above and a terminal connected to the communication apparatus, the terminal 

io comprising a terminal processor, a display unit and input means for inputting data by a user, the communication appa- 
ratus being arranged for passing a message received to the terminal if the terminal is indicated in the message to be 
the destination address, and the terminal processor is arranged to either merge the message with a designated HTML 
file or rf the designated HTML file is not found by the terminal processor, to create a defauh dynamic HTML 
[0046] Thus, user terminals that receive a message lor which the terminal processor does not have the corresponding 

is message definition can rely upon the system's automatic interpretation and display which is based upon the serf- 
descrbing information contained within the message received. This same serf-describing information can then be used 
by the terminal processor to automatically create a default database message definition if the database message defi- 
nition referred to by the message can be found. Such a default database message definition can then be edited and 
adapted to the local system by the terminal user. 

20 [0047] The present invention may include a state of the art solution for problems two and three combined in a unique 
way with completely new solutions to problems one and four, all built around a unique f lextole format electronic data 
message management system composed of the claimed flexible message format and communication apparatus. 
[0048] The message management system of the present invention, which is defined and controlled by detailed infor- 
mation stored in the tables of a relational database, allows for the most efficient, complete and simple to use way of 

25 communicating electronic data in flexible formats. The f textole message format allows the inclusion of any form of elec- 
tronic data. The flexible message format contains information that allows a receiver to interpret, understand and display 
the contents of the message, even if it has previously never been received. The receiver can also add this unknown 
message format to its own message database and link it into its business databases and an HTML user interlace very 
easily and quickly, without writing or changing any software. An HTML user interface can also be dynamically generated 

so by the software of any terminal in the case where there is no specified, previously created HTML file. This addresses 
the first issue. 

[0049] In the present invention, an ANSI standard SQL interface to the major relational databases may be provided. 
This interface provides the service of automatically linking the user selected fields of a data message to the fields in a 
relational database table, for subsequent storage or retrieval. This data mapping interface can also link to flat file for- 
35 mats such as fixed length fields and CSV (comma separated value) files. This data mapping interface can be expanded 
to link message data fields to many other formats, such as SNMP and manufacturing protocols for automatic process 
control. This data mapping interface is defined by entries in the ILMDB and controlled by the ILMS. This addresses the 
second issue. 

[0050] In the present invention, a message control user interface terminal may be provided, where a user may create, 
40 edit, receive, send and view messages. The message control user interface communicates to a network and message 
management server arranged in accordance with the invention. In essence, the present invention replaces the current 
webserver/web browser technology for those individuals or companies that need full data communications capability, 
and expands the system domain to include any data communications network. This allows the full sending and receiv- 
ing of HTML, VRML and Java appletes, as well as any specific data the user has defined to be in a particular message. 
45 When combined with the previously described features, this provides the full, database controlled linking between the 
data in a message, the customer data source it must be retrieved from or stored in, and the graphical user interface 
(HTML, etc.) it must be displayed with. 

[0051] In addition to solving the issues described above, the present invention has added the capability of defining 
automatic, system performed actions, that may be organized as message pre and post processing, or, in the case of 

so messages linked with a graphical user interface, field selection actions. These actions may be defined as SQL or as an 
"InterLingua™ Script". "Inter Lingua™ Script" (IS) is defined in the present invention and is a simple, yet powerful set of 
calculation, execution and conditional logic control statements, that are dynamically interpreted and executed in real- 
time, and can interact with all message data fields. The actions can generate a new message, call built in system func- 
tions and external programs or send and receive database queries. These actions can be used to generate an auto- 

55 matic message response, automatic field validation, perform calculations, run a Java applete or a complex database 
transaction, for example. 

[0052] In the present invention we have included the truly unique method of an application being defined as a set of 
messages and their associated actions. Due to the richness and f lexbilrty of the interaction between the messages; 
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their ability to run database transactions, merge with or generate graphical user interfaces, or run silently in the system 
as a background process, it is possible to fully define a complex application as a collection of data messages and their 
associated actions. This also has vast implications in the realm of distributed application processing, as these mes- 
sages are, by their very nature, sent, received, understood and organized with great ease, as a basic function of the 
system. This means that for the first time, a distributed application system could easily and flexibly define, without 
changing or adding any software code, the local user interface and customer data source interlace (such as the busi- 
ness database) at each site and still be using the same application (message set). 

Brief Description of the Drawings 

[0053] The invention will be explained with reference to some drawings which are only intended to illustrate and not 
to limit the scope of the invention. 

Figure 1 shows a general overview in block diagram of the system according to the invention; 
Figures 2a, 2b, 2c show a message format accorcfng to the invention. 

Description of the Preferred Embodiment 

[0054] In figure 1 a plurality of servers SRV(m), m = 1 , .... M, is shown. Any of the servers SRV(m) may be connected 
to one or more terminals. The terminals connected to server SRV(1 ) are referred to with ILMC(n), n= 1 N. The acro- 
nym "ILMC" has been derived from Intertingua™ Message Client. The connections are numbered with references 4, 5. 
[0055] Moreover, server SRV(1) is connected to a customer database CDB(1). Although one customer database 
CDB(1) is shown, more than one can be applied as required. 

[0056] Terminal ILMC(1) has been depicted in greater detail in figure 1 . Terminal ILMC (1) is shown to include a mon- 
itor screen 6. a processing unit 1, a keyboard 12, and a mouse 13. The keyboard 12 and the mouse 13 are connected 
to the processing unit 1 . Of course, any other known means for inputting data to the processing unit 1 by a user is pos- 
stole instead of or in addition to the keyboard 12 and the mouse 13. 

[0057] The monitor screen 6 shows some "buttons" 7, 8, 9, 1 0, 1 1 . These buttons can be acted upon by the user by 
means of the mouse 13 to instruct the processing unit 1 to carry out predetermined tasks. Such predetermined tasks 
may be the opening of options, establishing connections, sending messages, receiving messages, and/or loading of 
data into the memory of the processing unit 1 . 

[0058] The server SRV (1) is provided with a processor called InterLingua™ message server ILMS lor receiving, pass- 
ing or sending messages in accordance with the method of the present invention. Part of the ILMS processor is indi- 
cated with IS (= InterLingua™ Script), the function of which will be explained later. 

[0059] Server SRV (1) also comprises a database ILMDB (= InterLingua™ Message Database) for storing several 
tables in accordance with the present invention, as will be explained later. 

[0050] The server SRV (1) is arranged for point-to-point communication with one other server through a communica- 
tion path 2. The communication path 2 may be established in any known way, i.e., either by wires or wireless. 
[0061 ] Figure 1 shews several other servers SRV (m) connected to one or more terminals ILMC's. These further serv- 
ers SRV (m) are organized in accordance with the present invention further explained in detail below. 
[0062] Figures 2a, 2b, and 2c show a message format. In figure 2a, the message format is shown to include four fields 
MSG Id, MSG Class, MSG Version and MSG Creator, used as message definition references by any apparatus receiv- 
ing the message. 

[0063] The field MSG Id is to identify the message. 

[0064] The MSG Class is used to designate a category or type of message, like mail, business message, orders, or 
shipping. 

[0065] The field MSG VERSION comprises a message version identifier for identifying a version number of the mes- 
sage concerned. 

[0066] The fourth field MSG CREATOR comprises a message creator identifier for identifying a creator of the mes- 
sage concerned. 

[0067] The MSG Id, Class and Version fields are integer values. There are, e.g., 1 ,000,000 MSG Ids per MSG Class 
and 10,000 MSG Classes. Every MSG Id, MSG Class pair can have, ag., 100 MSG Versions. MSG Classes may ag. 
be arranged as follows. MSG Classes 1 to 20 are reserved for the ILMS. MSG Classes 21 - 100 are predefined catego- 
ries such as order placement, shipping, etc. The 9900 remaining MSG Classes are for user definition The MSG Creator 
may ag. have 80 characters. This is for the purpose of identifying entire message sets created by particular users or 
companies for easy automatic transfer. 

[0068] Together with five more fields these message definition references form a header to the messaga These five 
more fields are: SENDER Id. DESTINATION ADDRESS, ENCRYPTION TYPE. COMPRESSION TYPE, AND APPLI- 
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CATION NAME. 

[0069] The Sender Id is the user name as recognized by the server SRV(m) with the name of the server SRV(m) 
appended, e.g., in a manner similar to an email address (i.a user-xyz@ilserver.com). The field DESTINATION 
ADDRESS is for identifying the address to which the message concerned is to be transmitted. The destination address 
5 may be of the same format as the SENDER Id. 

[0070] The field ENCRYPTION TYPE is used for a reference to a type of encryption applied, if one is required. The 
field COMPRESSION TYPE is to indicate the type of compression used, if required. 

[0071] The field APPLICATION NAME is used for indicating whether or not the message concerned is member of a 
series of messages which together form one application. 

io [0072] The Field Count gives the number of fields, e.g., from 0 to 256 in the message. The actual field data follows 
this field, if the count is more than 0. With reference to figure 2b, a field is defined by a Type identifier, a Size value, a 
field Name for internal identification, a field Label for default display, and a field Description, also for default display. The 
length data following is know by combining the information of the Type and Size fields. One field definition follows 
directly after another with no additional separators. 

75 [0073] Very often, particularly in HTML type data, there is a reference to a local file containing binary image, sound 
or program data. To insure the correct transfer and referencing of these referenced external objects, they are automat- 
ically grouped at the end of the message, as shown in figure 2a The fields that reference them are made to point to the 
objects. When the message is received, these objects are automatically stored locally and the field references are auto- 
matically adjusted to access the objects in their new location. The Object Count field gives the number of objects in the 

20 message from 0 to 256. The object data follows this field, if the count is more than 0. An Object is, preferably, defined 
by a MIME Type/Content identifier, a Size value and then the actual Object Data, as shown in figure 2c. One Object def- 
inition follows directly after another, with no additional separators. 

[0074] A digital signature, using a server SRV key, is, preferably, created on the entire message and added at the end 
of the Object list 

25 [0075] The allowed data types as defined in figures 2a, 2b, 2c are for instance: 

1) Unicode character strings; 

2) Computer hardware independent integers of any size; 

3) IEEE 8-byte format floating point numbers; 
30 4) Universal Resource Locators (URL); 

5) Image data in GIF or JPEG format; 

6) MIME specified data representations. 

[0076] In actuality, GIF and JPEG data are also included as MIME types. The decision to make a specific data type 
35 for images in these formats was driven by the frequency of their use in HTML types of display systems. The most com- 
monly used data types have their own definition. Any additional data types can be included as existing MIME types or 
specific MIME extensions. These data types are specified by way of example only. The scope of protection of the 
present is not intended to be limited by the type of data preferred. 

[0077] Each message may have its own digital signature and optional encryption and/or compression, which is man- 
40 aged automatically by the server SRV(m). 

Message Database 

[0078] A flexWe message format definition, management and control system is implemented using database ILMDB 
45 as a relational database as a holder of 

a) detailed message definitions; 

b) message mapping instructions: 

so b.1) mapping to customer database fields; 

b.2) mapping to customer flat fie formats; 

b.3) mapping to customer user interface (HTML) fields; 

b. 4) mapping to other message fields; 

55 c) message action lists: 

(SQL, Java, calculations, logic flow, message calls, external program calls) 

c. 1) message pre-processing actions; 
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c.2) message post-processing actions; 

c.3) message field user interface event actions (1 per field). 

[0079] This information is held in tables in the relational database ILMDB and allows the system to fully interpret and 
5 process any message. New message definitions may be added and old definitions may be changed. Message defini- 
tions may be sent from one server SRV(m) to another for immediate incorporation into the message database ILMDB. 
Every flextole message format includes enough serf-description information in itself to allow a server SRV(m) to inter- 
pret a previously unseen message and create a new message definition entry in the ILMDB for it automatically. This 
new message definition may be edited and enhanced by a system administrator, to complete the mapping into the 
w receiver's system. 

[0080] Message data is not kept in the database ILMDB, only the definition. The message data is kept in compressed 
files on a disk storage system. These files are periodically either archived or deleted according to the server message 
duration options chosen by the system administrator. 

[0081] The primary relational tables within the database ILMDB needed to define and control a message either 
is received or to be sent are as follows: 



Table Name 


Description 


msgdef 


Inter Lingua™ Message Definition 


flddef 


Message Field Definition 


fldmap 


Field Mapping 


fkJact 


Field Action Definition (one action per field) 


msgpre 


Message Pre-processing (sequence of message actions) 


msgpost 


Message Post-processing (sequence of message actions) 



30 

[0082] System developers skilled in the art will recognize that there are many other tables of related information nec- 
essary to make an entire system more easily usable, and control secondary system features. Examples of this might 
be all of the tables associated with user accounts and user information, system administration and system security. The 
tables presented here are the core tables necessary for implementing the present invention in accordance with the pre- 
35 ferred embodiment, and extensions or enhancements are considered to be within the scope of the present invention as 
well. 



Table 



40 


msgdef 


45 


This table is responstole for holding the primary definition of a messaga A message is completely identified by the 
first four fields of this table, which are also in the message header (ct figure 2a). The fifth field (msyskJ) is an identi- 
fier that is assigned internally by the server processor ILMS, and is used as a reference for identification of and fast 
access to other tables within the database. 




Field Name 


Type 


Description 




msgid 


integer 


Message Identifier 




msgver 


integer 


Message Version 


50 


msgclass 


integer 


Message Class 




creatid 


char 


Creator Identifier 




msyskt 


integer 


Message System Id 


55 


creatdate 


date 


Date Created 




usedate 


date 


Date Used 




These two fields control how long a message is stored by the ILMS . 
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Table (continued) 





msgdef 


5 


This table is responsible for holding the primary definition of a message. A message is completely identified by the 
first four fields of this table, which are also in the message header (cf. figure 2a). The fifth field (msysid) is an identi- 
fier that is assigned internally by the server processor ILMS, and is used as a reference for identification of and fast 
access to other tables within the database. 




durdays 


integer 


Duration Days 


10 


durmins 


integer 


Duration Minutes 




777ese two fields identify the type of encryption and digital signature algorithm. 




encrtype 


char 


Encryption Type 


15 


sigtype 


char 


Digital Signature Type 


This field indicates whether the message is for display or not. 




silent 


boolean 


Message Silent Rag 




This field indicates whether the message can initiate or respond to actions. 




active 


boolean 


Processing Enable Flag 




msgicon 


char 


Message Icon File (for ILMC display) 




msghtml 


char 


Message HTML File (for ILMC 
display) 


25 


This field indicates whether the message is the first in an application. 




appmain 


boolean 


Application Main Rag 




77?is field contains a name if the message is part of an application. 


30 


appname 


char 


Application Name 


descr 


char 


Message Description 



Table 



fkJdef 


This table is responsible for holding the primary definition for all fields of all messages. A field is 
uniquely identified by the 'msysid' assigned in the 'msgdef table and either a field sequence 
number (fldseq) or a field name (fldname). 


RekJ Name 


Type 


Description 


msysid 


integer 


Message System Id 


fldseq 


integer 


Field Sequence 


fldname 


char 


Reld Name 


77?ese three fields are used to create 1, 2(tables) t or 3 dimensional arrays. 


ar1 


integer 


Array Dimension 1 


ar2 


integer 


Array Dimension 2 


ar3 


integer 


Array Dimension 3 


fkftype 


char 


Reld Data Type 


The field size is interpreted differently, depending on the data type. 


fldsize 


integer 


Reld Size 
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Table (continued) 




fkJdef 


This table is responsive for holding the primary definition for all fields of all messages. Afield is 
uniquely identified by the 'msysid' assigned in the Ynsgdef table and either a field sequence 
number (f Idseq) or a field name (fldname). 


This field is used if the field is a reference to another message as a data structure. 


smsysid 


integer 


Sub-Message System Id 


These two fields are used if the field contains MIME data. 


mimecont 


char 


MIME Content Identifier 


mimetype 


char 


MIME Type Identifier 


fkHabel 


char 


Field Label (for ILMC display) 


fldcom 


char 


Field Comment (for ILMC display) 



Table 



fldmap 


This table is responsible for holding any mapping information that a field might use. This table can define mappings 
to database fields, flat file fields and other message fields. The field is identified in the same manner as table llddef. 
There is one mapping for data and one mapping for display allowed for each field, except in the case where a field is 
def ined as an array. A data and display mapping can be assigned to one or more elements or dimensional rows of 
an array. 


Field Name 


Type 


Description 


msysid 


integer 


Message System Id 


fldseq 


integer 


Field Sequence 


fldname 


char 


Field Name 


These three fields allow mappings to specific array elements or dimension rows . 


art 


integer 


Array Dimension 1 


ar2 


integer 


Array Dimension 2 


ar3 


integer 


Array Dimension 3 


This field allows the data to be transferred from the most recently active previous message within the same message 
context, which is the set of currently active messages for a particular user connection. 


cpyfld 


char 


Copy Field (From Msg) 


These three fields are used to specify a particular field in a SQL accessible relational database. 


dbnam 


char 


Database Name 


tblnam 


char 


Table Name 


fldnam 


char 


Field Name 


This field specifies a field in an HTML file (msgdef.msghtml) for display. 


tagnam 


char 


HTML Tag Name 


These two fields specify a flat file of either fixed field lengths, or comma separated values. 


flatfile 


char 


Flat File Name 


filetype 


char 


File Type (Fixed, CSV) 
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Table (continued) 





fldmap 


5 


This table is responsible for holding any mapping information that a field might use. This table can define mappings 
to database fields, flat file fields and other message fields. The field is identified in the same manner as table tiddef. 
There is one mapping for data and one mapping for display allowed for each field, except in the case where a field is 
defined as an array. A data and display mapping can be assigned to one or more elements or dimensional rows of 
an array. 


10 


These four fields specify the field location for the flat file. 


rowbegin 


integer 


Row Begin 




cobegin 


integer 


Column Begin {or Field # for CSV) 




rowend 


integer 


Row End 


15 


colend 


integer 


Column End 



Table 



fldact 


This table is responsible for holding any action information that a field might use. There is one 
action per field, except in the case where a field is defined as an array. An action can be 
assigned to one or more elements or cfimensional rows of an array. 


Reld Name 


Type 


Description 


msysid 


integer 


Message System Id 


fHseq 


integer 


Reld Sequence 


fldname 


char 


Reld Name 


art 


integer 


Array Dimension 1 


ar2 


integer 


Array Dimension 2 


ar3 


integer 


Array Dimension 3 


This field defines the action type: SQL or IS, file or local. 


acttype 


char 


Action Type 


This field contains SQL, IS or a file name whose contents are SQL or IS. 


actscnpt 


char 


Action Script 



Tables: msqpre and msqpost 

45 

[0083] The two tables msgpre and msgpost have an identical structure. Table 'msgpre' holds the list of actions to be 
executed by server processor ILMS as pre-processing for a particular messaga This means before any display or field 
actions take place, the server processor ILMS completes the list or pre-process functions. Table 'msgposf holds the list 
of actions to be executed by the server processor I LMS as post-processing for a particular messaga This means that 
so after all other message actions and displays have completed, the server processor ILMS completes the list of post-proc- 
ess functions before deleting the message from main memory. The process sequence number is used to create a con- 
trolled execution of the list of actions. A previous sequence number must complete before the next one can begin, ff 
there is more than one action with the same sequence number, they are started at the same time, or, within a multiple 
CPU or massively parallel environment as true parallel processes. 

55 
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Table 



msgpre 


Field Name 


Type 


Description 


msysid 


integer 


Message System Id 


procseq 


integer 


Process Sequence 


This field defines the action type: SQL or IS, file 


or local. 






proctype 


char 


Pre-processType 


This field contains SQL, IS or a file name whose 


contents are SQL or IS. 




procscript 


char 


Pre-process Script 



Table 



msgpost 


Field Name 


Type 


Description 


msysid 


integer 


Message System Id 


procseq 


integer 


Processing Sequence 


This field defines the action type: SQLor IS, file or 


local. 






proctype 


char 


Post-processType 


77ms field contains SQL, IS or a file name whose 


contents are SQL or IS. 




procscript 


char 


Post-process Script 



InterLinaua™ Script (Action Definition and Control Languag e) 

[0084] Any action, for either message pre-processing, post-processing or field actions can be either an SQL-action 
or IS-acfion. SQL (Structured Query Language) is an ANSI standard interface language for relational databases. IS 
(lnterLingua™ Script) is a predetermined part of the server processor ILMS (cf. figure 1) and is a small, but powerful set 
of calculation, execution and conditional logic statements that give application level functionality to a message. In a pre- 
ferred embodiment, the definition of IS is as follows: 

Calculation 

[0085] The operations of add (+), subtract (-), multiply (*) and divide (0 are allowed upon integers and floating point 
values. Parenthesis "( )" are allowed for grouping mathematical operations. 

Assignment 

[0086] Assignment (=) is allowed to integers, floating point values, strings and URLs. 
Logical and Conditional 

[0087] Symbols representing: and (AND), or (OR), greater than (>), less than (<), greater than or equal to (>=), less 
than or equal to (<=). equality (=), not equal (!=), and negation (I) are allowed upon integers, floating point values. 
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strings and URLs. 
Control Row 
5 [0088] 

END-MSG - End a message. Kjst be last command from Its own pre-processing 11st. 

END-APP - End an application. Must be last command from a member message post- 

processing list. 

For Loop: 

FOR i - x TO y 
BEGIN 

<statemerrts> 

END 

While Loop: 

WHILE <cond1t1on> 

BEGIN 

25 

<statements> 

END 



15 



20 



If -Then-Else: 

30 

IF <cond1tion> THEN 
BEGIN 

<statements> 

END 

35 

ELSE 
BEGIN 

<statements> 

END 

40 

Command 

Load mapped field data: 

45 LOAD {WHERE <extemal field name> = <value>} 



50 



55 
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Store mapped field data: 

STORE (WHERE <external field name> - <vali*») 

5 

Execute external program; 

CALL [ JAVA • EXEC * SHELL ] <program nams> <paran»t*r 1> ... <pamt«r o> 

"> Execute message: 

ILMP://<host-naffie>/<message 1d> 
Execute internal function (this is used mostly for user interface 

75 

events) : 

ILHP://<host-nMe>/<nte3saQe id>/<field 1d> ( UI-ACT • MSG-END • APP-END ] 
ILMP://<host-n«»e>/<messa9e 1d>/<f1e1d 1d> [ AOD-MTA * DEL-DATA » CHG-DATA ) <data> 

20 



A pplications 

25 

[0089I A collection of InterLingua™ messages may be grouped together, uniquely named and used as an InterLin- 
gua™ application. For the purposes of this discussion, for any programming language or system platform, an application 
is defined as being one or more functions whose sequence of operation may vary depending upon input data and user 
and system events; that can access and interact with external storage devices; and that can interact with users through 
30 a user interface 

[0090] All or part of this named set of messages may reside on one or more servers SRV(m) in one or more locations. 
This named set of messages, or application, implements: 

a) a directed series of functions 
35 b) local and shared data 

c) user interface screens 

d) networked distributed application functionality 

[0091] The directed series of functions may include any of the action types, such as database queries, calculations 
40 and the activation of additional messages. Activating a message in this context can be used for the equivalent of calling 
an application function, displaying the next user interface screen, or, of course, sending a message to a local or external 
network destination. The real-time structured flow of the order of operations, or, in other words, the directed series of 
functions, is determined by the message action fists and also event actions generated by the user interface, such as a 
mouse selection of a field or a button. 
45 [0092] The local and shared data includes any of the allowed data typed. These data types may be grouped into data 
structures. This message data may be mapped to and from user databases, user interfaces and passed to other mes- 
sages. This concept makes use of a message as a function that may have its own local data and may call other func- 
tions (messages) to which it may pass any local data. When this local data is passed between two or more messages 
it becomes shared data. 

so [0093] The networked cfistrtouted application functionality is implemented by using the inherent capabilities of the 
InterUngua™ clients ILMC(n) and serves as message senders and receivers, ff an application set is created to run in a 
distributed manner across several servers as contrasted to a single application on one server, the primary difference 
will be that one or more of the messages acting as an application function will have a remote server as its destination, 
rather than the local server. This makes the creation of networked distributed applications very straightforward, with a 

55 simplicity and flexibility that has not been seen before. 
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InterLinquq™ Message Qlient (ILMC) and Server $RV 

[0094] The software of the Interlingua™ Message Client (ILMC) is, preferably, written entirely in Java, thus ensuring 
that it can run on any Java enabled computer system, which includes almost all of the most commonly used computers. 
5 The ILMC functions as an HTML/VRML/Java Applete display console and as a network communication interface to the 
server SRV(m). 

[0095] The user interface screens make use of the ability to associate a message with an HTML definition and map 
the data between the message and the HTML display. This allows the chosen functions (messages) to have a user 
interface as necessary. User keyboard and mouse events are linked to field actions. 

io [0096] The communication sub-system, implementing the message send/receive functions from one server to an 
other server and between a server and a terminal ILMC, is designed to work in a highly optimized, multi-threaded fash- 
ion, and replaces the use of checksums for monitoring message integrity with the use of digital signatures. This allows 
for complete confirmation of the non-corrupted state of the received message and, at the same time, the security veri- 
fication of the identity and authenticity of the sender. The communication sub-system exists in both the server SRV and 

is the terminal ILMC. The communication sub-system is designed to be network protocol independent In its current ver- 
sion it will run on TCP/IP, XTP/IP and XTP/ATM/AAL5, but H will just as easily run on AppleTalk, IPX, SNA, X.25, DEC- 
NET, OSI or any other protocol that can use a socket interface and point-to-point addressing scheme. 
[0097] The communication sub-system is not a critical part of the present invention. The advances of the present 
invention may be implemented over many different types of communication sub-systems. Those skilled in the art will 

20 recognize that the type and implementation details of the chosen network communications sub-system will not change 
the functionality of the present invention, as long as the communication sub-system has a reliable delivery protocol that 
can guarantee a high rate of delivery success and data integrity. 

[0098] A message priority scheduling and service mechanism as descrfced and claimed in European Patent Appli- 
cation 97202945.8 may be added to the communication sub-system. This mechanism uses separate connections for 
25 individual priority levels and a simple network and system buffering algorithm to automatically guarantee fair service for 
all message priority levels. This mechanism delivers high priority messages faster consistently, without the need for a 
complex scheduling algorithm to monitor message sizes or prevent lower priority message lock-out 

Receiving A Message 

30 

[0099] When a message is received by a server SRV(m), it will pass through the communication sub-system. The 
digital signature will be verified and the transport layer header will be stripped. If the message has been encrypted or 
compressed it will be decrypted or decompressed at this time. The message will then be passed to the database layer 
ILMDB. 

35 [0100] If message definitions are absent at a desired location, entire database message definitions may be 
exchanged automatically for particular messages or groups of messages, thereby creating easily exchanged common 
format messages for multiple users. 

[0101] Alternatively, if a message definition does not exist for the message received it will be sent to the in-box of the 
system administrator. The system administrator can then examine the message using a terminal ILMC, automatically 
40 add the basic message definition and link the message fields to local database fields and HTML display fields as nec- 
essary. The system administrator may also automatically request that the sender of the message send the complete 
message definition which will then automatically be placed in the local database ILMDB. This request is sent out as a 
message from one server to another server. 

[01 02] If a message definition exists for the message received, it will be read from the database ILMDB. The message 
45 pre-processing action lists will be executed by the server SRV(m), enacting functions such as message field validation, 
database queries, calculations and other messages. If the message is sent to a user for display, the processor 1 of ter- 
minal ILMC will either merge the message with the designated HTML fie or if the designated HTML file is not found by 
processor 1 , it will create a default dynamic HTML The field actions may be activated by specific mouse and keyboard 
events if they have been defined in the message. Field actions may call a standard HTTP URL, send a request for the 
so display of local image, activate a SQL database transaction, update local display data or run an InterUngua™ Script (IS) 
command. H the message has no user interface defined it is referred to as "silent", and its presence in the system can 
only be seen by the system administrator. 

[01 03] At the completion of the silent message pre-processing and encountering an END-MSG command or the ter- 
minal message user interface sends an END-MSG command, the message post-processing action lists will be exe- 
55 cuted by the server SRV(m). If the message is part of an application set, it will remain active and in memory until the 
server SRV(m) encounters or receives an END-APR When an application set completes, all member message post- 
processing lists wiH be executed by the server SRV(m) if they have not yet been executed. This functionality also guar- 
antees the automatic maintenance of transaction context and application data and stata When a single message or 
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application set completes, the system memory will he cleaned and returned for use by other messages and applica- 
tions. 



Sending a Message 

5 

[01 04] From a terminal ILMC: 

[0105] A message format (ILMF) has been requested and received from the ILMDB/ILMS. The message content and 
address has been added by the terminal user. The terminal user initiates a message send, through a user interface 
action, to the server on which the user is registered. 

w [0106] From a server SRV(m): 

[0107] A message may be initiated automatically as the result of a direct call to activate a message on the server 
SRV(m) through InterLingua™ Script (IS), or may be the request of a connected terminal which is first received and 
processed by the server SRV(m). The server performs the message pre-processing if any is defined. If the destination 
address is for the server itself, the message post processing is executed after encountering or receiving an END-MSG, 

is then the message is terminated. If the destination address is for another server then the message is passed to the com- 
munication sub-system, compressed or encrypted, given a digital signature and then sent through a point-to-point con- 
nection to the receiving server. 



List of acronyms 

20 

[0108] 



ANSI 
CORBA 

25 CSV 
EDI 
GIF 
HTML 
HTTP 

30 ILMC 
ILMDB 
ILMF 
ILMP 
ILMS 

35 IS 

JDBC 
JPEG 
MIME 
ODBC 
40 RDBMS 
SNMP 
SQL 
URL 
VRML 



= American National Standard Institute 

= Common Object Request Broker Architecture 

= Comma Separated Value 

= Electronic Data Interchange 

= Graphics Interchange Format 

= Hyper Text Markup Language 

= HyperText Transfer Protocol 

= InterLingua™ Message Client 

= InterLingua™ Message Database 

= InterLingua™ Message Format 

= InterLingua™ Message Protocol 

= InterLingua™ Message Server 

= InterLingua™ Message Script 

= Java DataBase Connectivity 

= Joint Photographers Expert Group 

= Muli-purpose Internet Mail Extensions 

= Open DataBase Connectivity 

- Relational Database Management Systems 

= Simple Network Management Protocol 

= Structured Query Language 

= Universal Resource Locator 

= Virtual Reality Markup Language 



45 



Claims 



1 . Method of point-to-point communication between a sender (SRV(m)) and a receiver (SRV(m)) by means of mes- 
sages with flexible message formats (ILMF) characterized in that any of said messages comprises: 

50 

- a header at least comprising message definition references (MSG ID, MSG CLASS, MSG VERSION, MSG 
CREATOR), a sender identifier (SENDER ID) and a destination address (DESTINATION ADDRESS); 

- message content regarding: 

55 * number of fields (FIELD COUNT) and content of any field (FIELD(1), ...); 

* number of objects (OBJECT COUNT) and content of any object (OBJECT(1). ...). 

2. Method according to claim 1 , wherein said message definition references comprise a message identifier (MSG ID) 
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for identifying any of the messages. 

3. Method according to claim 1 or 2, wherein said message definition references comprise a message class identifier 
(MSG CLASS) for identifying a message class for any of the messages, like mail, business message, orders or 

5 shipping. 

4. Method according to any of the preceding claims, wherein said message definition references comprise a message 
version identifier (MSG VERSION) for identifying a version number of any of the messages. 

io 5. Method accorting to any of the preceding claims, wherein said message definition references comprise a message 
creator identifier (MSG CREATOR) for identifying a creator of any of the messages. 

6. Method according to any of the preceding claims, wherein said header comprises a reference to a type of encryp- 
tion (ENCRYPTION TYPE) applied. 

75 

7. Method according to any of the preceding claims, wherein said header comprises a reference to a type of compres- 
sion (COMPRESSION TYPE) applied. 

8. Method according to any of the preceding claims, wherein said header comprises a reference to an application 
20 (APPLICATION NAME) for indicating whether or not any of the messages is member of a series of messages form- 
ing together said application. 

9. Method according to any of the preceding claims, wherein any of said messages comprises a digital signature 

25 1 0. A communication apparatus comprising processing means (ILMS) and a database (ILMDB), arranged for point-to- 
point communication with another communication apparatus (SRV(m)) by means of messages with flexHe mes- 
sage formats (ILMF), said messages comprising: 

- a header at least comprising message definition references (MSG ID, MSG CLASS, MSG VERSION, MSG 
30 CREATOR), a sender identifier (SENDER ID) and a destination address (DESTINATION ADDRESS); 

message content regarding: 

* number of fields (FIELD COUNT) and content of any field (FIELD(1), ...); 

* number of objects (OBJECT COUNT) and content of any object (OBJECT(1), ...); 

35 

said processing means (ILMS) being arranged for consulting a predetermined message definition table (msgdef) 
stored in said database (ILMDB) using said message definition reference as a reference to said predetermined 
message definition table. 

40 1 1 . A communication apparatus according to claim 10, wherein said predetermined message definition table (msgdef) 
comprises a message identifier (msgkJ) for identifying any of the messages. 

12. A communication apparatus according to claim 10 or 11, wherein said predetermined message definition table 
(msgdef) comprises a message class identifier (msgdass) for identifying a message class for any of the messages, 

45 like mail, business message, orders or shipping. 

13. A communication apparatus according to any of the claims 10 through 12, wherein said predetermined message 
definition table (msgdef) comprises a message version identifier (msgver) for identifying a version number of any 
of the messages. 

50 

14. A communication apparatus according to any of the claims 10 through 13, wherein said predetermined message 
definition table (msgdef) comprises a message creator identifier (creatid) for identifying a creator of any of the mes- 
sages. 

55 15. A communication apparatus according to any of the claims 10 through 14, wherein said predetermined message 
definition table (msgdef) comprises a reference to a type of encryption (encrtype) applied. 

16. A communication apparatus according to any of the claims 10 through 15. wherein said predetermined message 
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definition table (msgdef) comprises a reference to a digital signature type (sig-type) applied. 

17. A communication apparatus according to any of the claims 10 through 16, wherein said predetermined message 
definition table (msgdef) comprises a message system identifier (msysid) for use as a reference to further tables in 

5 said database (ILMDB). 

18. A communication apparatus according to any of the claims 10 through 17, wherein said further tables comprise a 
field definition table (flddef) for holding primary definitions for any field of said messages. 

10 19. A communication apparatus according to any of the claims 10 through 18, wherein said further tables comprise a 
field mapping table (fUmap) comprising mapping information usable by predetermined fields, e.g. for mappings to 
hyper text markup language fields, database fields, flat file fields and other message fields, said database fields 
and flat fie fields being stored in a customer database (CDB). 

75 20. A communication apparatus according to any of the claims 10 through 19, wherein said further tables comprise a 
field action table (fldact) comprising action information usable by predetermined fields. 

21 . A communication apparatus according to any of the claims 10 through 20, wherein said further tables comprise a 
message pre-processing table (msgpre) comprising a list of actions to be executed as pre-processing for a mes- 

20 sage either received or to be sent and a message post-processing table (msgpost) comprising a list of actions to 
be executed as post-processing for a message received. 

22. A communication apparatus according to any of the claims 20 or 21 , wherein said field action table (fldact), said 
message pre-processing table (msgpre) and said message post-processing table (msgpost) comprise references 

25 to types of action selected from the following group of actions: mathematical calculations, assignments, logical 
operations, concitional operations, and commands. 

23. A communication apparatus according to any of the claims 10 through 22, wherein said message definition table 
(msgdef) comprises an application field (appmain) for indicating whether a message received is a first message of 

30 an application and an application name field (appname) for referring to a name of said application. 

24. A communication apparatus according to claim 23, wherein said application is a distributed application distributed 
over a plurality of communication apparatuses. 

35 25. A communication apparatus according to any of the claims 10 through 24, wherein said apparatus is arranged for 
requesting a new message definition from a sender if a message received refers to a message definition not 
present in its database (ILMDB), and receiving said new message definition from said sender and storing rt in said 
message definition table (msgdef) in said database (ILMDB). 

40 26. A communication apparatus according to any of the claims 10 through 25, wherin said processing means (ILMS) 
are arranged to either merge a message received with a designated HTML fie or rf the designated HTML fie is not 
found by the processing means (ILMS), to create a default dynamic HTML file. 

27. A system comprising a communication apparatus (SRV(m)) according to any of the claims 10 through 25 and a ter- 
45 minal (ILMC) connected to said communication apparatus, said terminal comprisffig a terminal processor (1), a dis- 
play unit (6) and input means (12, 13) for inputting data by a user, said communication apparatus being arranged 
for passing a message received to said terminal if said terminal is i repeated in the message to be the destination 
address, and said terminal processor (1) is arranged to either merge the message with a designated HTML file or 
if the designated HTML file is not found by the terminal processor (1), to create a default dynamic HTML 

50 



55 
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